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(54) Title: NETWORK CONTROLLER FOR DIGITALLY CONTROLLING REMOTE DEVICES VL\ A COMMON BUS 

(57) Abstract: The present invention provides a network controller that directs communications with a variety of remote devices 
via a common bus. The network controller includes a transmitter for transmitting messages via the common bus, and a receiver 
for receiving messages from the common bus. Additionally, the network controller includes a clock for providing clock signals to 
both the transmitter and receiver. The transmitter and receiver are selected such that the network controller is capable of selectively 
operating in either synchronous or asynchronous mode. In operation, the network controller is configured in either a Manchester 
encoding or a Universal Asynchronous Receiver Transmitter (UART) protocol. The transmitter transmits messages comprising a 
command and an address of at least one remote device. In one embodiment, the transmitter simultaneously transmits messages to a 
plurality of remote devices in accordance with a group address comprised of a multiple bits with each bit associated with a respective 
group. 
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NETWORK CONTROLLER FOR DIGITALLY CONTROLLING 
REMOTE DEVICES VIA A COMMON BUS 

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
1 0 This invention was made with government support under Cooperative 

Agreement No. NCCW-0076 awarded by NASA. The govemmmthas certain rights 
in this invention. 

CROSS-REFERENCE TO RELATED APPLICATIONS 

1 5 The present application claims priority from U. S . Provisional Patent 

AppUcations S/N 60/254,137, entitled: NETWORK CONTROLLER FOR 
DIGITALLY CONTROLLING REMOTE DEVICES VIA A COMMON BUS filed 
on December 8, 2000, the contents of which are incorporated herein by reference. 

20 FIELD OF THE INVENTION 

The present invention relates generally to network controllers and, more 
particularly, to an apparatus and method for digitally directing communications with a 
variety of remote devices via a common bus. 

25 BACKGROUND OF THE INVENTION 

In many industries today, monitoring systems are used to assess either possible 
system failures or the affects of environment and other extemal forces on an object of 
interest For example, in the avionics industry, monitoring systems are employed to 
monitor parameters, such as strains, acceleration, pressures, corrosion, and 
30 temperatures at various critical structural locations on aircraft. Similarly, such 

monitoring systems could be used in the automobile industry to control and monitor 
everything from on/off occupant controls to drive-train controls and multimedia 
systems. 
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Many of these coaventional monitoring systems use a plurality of remote 
devices, such as sensors, actuators and subsystems that are placed about the obj ect 
being monitored at the critical locations. Many of these conventional monitoring 
systems utilize dedicated analog signal connecting, thus makmg the monitoring 

5 system dedicated to the application and complicating the wiring systems with separate 
wiring to each device to be monitored. Where networking exists there is often many 
multiplexer units networked together that gather many individual analog signals. 
While the analog wiring is now shorter, a significant amount of dedicated wiring to 
individual transducers still exists. Further, existing and proposed "smart transducer" 

10 protocols, which permit signal conditioning at the transducer and offer a fully digital 
networkmg solution without significant analog signal wiring, oftailack time- 
determinism, speed, simplicity to achieve cost eff^ectiveness in most applications. 

J} In many industries today, including the avionics and automotive industries, the 
complexity of the network may make many conventional monitoring systems 

15 impractical for a number of reasons. Specifically, the dedicated wiring and signal 
conditioning can be e^^ensive, bulky, heavy and hard to install and maintain. This is 
especially critical in aircraft applications, where weight concerns are at the forefront. 
Further, in the automotive industry, the added wiring may add to the weight and 
possibly the size of the car. In addition, dedicated wiring and signal conditioning 

20 renders automotive electronic-control modules application specific and thus more 
costly. Further, dedicated wiring Umits the amount of factory and dealer available 
options available due to the extra cost of preparing an automotive platfoimfor the 
options with extra harnessing and interfaces. 

Additionally, as stated, many conventional monitoring systems transmit data 

25 in an analog format. Typically, analog signals are susceptible to noise introduced into 
the signals during data transmisaon. Given that many of the transmitted signals have 
a low amplitude to start with, this noise can corrupt agnals as tiiey propagate from the 
transducer to the signal conditioner. Further, as many of these remote devices are 
scattered a fair distance from the controller, the electrical lines coimecting the remote 

3 0 device to the controller may be suffici^tly long to cause signal degradation due to 
DC resistance. 

In light of this, it would be advantageous to replace the dedicated wiring and 
the analog transmission with a common bus and digital transmission of data. But, 
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many coaventional digital networks suffer from a variety of problems themselves. 
For example, many existiag digital networks demand complicated protocols requiring 
processors and, tlius, suffer from high overhead network communication. The use of 
processors in such systems results in buUcy and more expensive network interfaces. 

5 Additional problems include low maximum bit rate, low effective data rate (due to 
overhead), expensive physical layers, and low network device count. Moreover, 
many computer systems that include digital networks do not operate in a time- 
deterministic manner. These computer systems generally lack the capability to 
schedule a trigger command to the network components that repeats with any 

10 precision timmg. 

In light of the foregoing, it would be advantageous to provide a network 
system that allows network components to digitally communicate over an 
inexpensive, simple and high-speed, yet robust, network line with a simple message 
protocol, small component size and low wire count. The network system would also 

1 5 advantageously operate without the use of a microcontroller or processor for the 
network components. Also, the network system would support both acquisition and 
control, acquire data simultaneously from the components and operate 
synchronized data samples from the components. Further, the network system would 
allow for high component counts, longer network lines and insure time-determinism 

20 in a precise maimer. 

SUMMARY OF THE INVENTION 
In view of the foregoing background, the present invention therefore provides 
a network controller for digitally directing communications with a plurality of remote 

25 devices via a common bus. The network controller of the present iavention allows 
various remote devices to communicate in either synchronous or asynchronous modes 
over an inexpensive, simple and high-speed, yet robust, network line with a simple 
network protocol, small component size and low wire count Advantageously, the 
network controller of the present invention cormects to the remote devices via a 

30 cormnon network, thereby permitting the various remote devices to share the same 
wiring for communicating with the network controller. Additionally, the network 
controller of the present invention allows for high component counts, longer network 
lines, and insures time-determinism in a precise maimer. The network controller also 
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allows data to flow to and from the remote devices at an alterable bit rate, supports 
both acquisition and control, and acquires synchronized data simultaneously from the 
remote devices using either an optional continuously synchronous clock, or a 
synchronized state change during asynchronous communication (often referred to as 
5 "isochronous"). 

Further, the network controller operates in conjunction with a network 
protocol that allows the controller to communicate with dther one or several r^ofe 
devices at a time across the network. Importantly, the network protocol has a fixed, 
low-level instruction set. Due to the simpUcity of the network protocol, the network 

10 controller of the present invention can operate with remote devices that lack a 

processor and, instead, comprise state machines that use pass throughlogic to process 
the commands and data between the network controller and the remote devices. 

As previously stated, the network controller of the present invention allows 
various remote devices to digitally communicate in either synchronous or 

15 asynchronous modes over an inexpensive, simple and high-speed, yet robust, common 
network. The network controller is capable of conmiunicating with sensors, actuators 
and subsystems, thus allowing for both acquisition and control. The network 
controller also includes a transmitter for digitally transmitting messages via a 
common bus, and a receiver for receivmg messages from the common bus. 

20 Additionally, the network controller contains a clock for providing clock signals to 
both the transmitter and receiver. The transmitter and receiver are selected such that 
the network controller is capable of selectively operating in either synchronous or 
asynchronous mode. In synchronous mode, the transmitter digitally transmits both 
the messages and clock signals via the common bus. And, in the asynchronous mode, 

25 the transmitter digitally transmits messages at a predetermined bit rate without any 
accompanying clock signals via the common bus. 

To fijrther allow the network controller to receive synchronized data samples 
from the remote devices, in one embodiment, the network controller further includes a 
clock transmitter for transmitting the clock signals via the conamon bus. This clock 

30 signal is used by the remote devices in a synchronous mode to clock in and clock out 
data. In the asynchronous mode where the reoaote devices operate based on bit rate as 
opposed to a synchronous clock signal, the clock transmitter operates at a constant, 
null, level. In another embodiment, the network controller issues a baud select 
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command that defines the predetermined bit rate at which the transmitter will transmit 
messages in the asynchronous mode. Additionally, in embodiments where the 
network controller operates in asynchronous mode, the receiver receives messages 
from the common bus based on the bit rate at which the messages are transmitted by 
5 the controller. Further, all of the ranote devices can synchronize in a singular manner 
to a predetermined state-change bit within the message often referred to as 
isochronous mode. 

In yet another embodiment, the transmitter of the network controller is • 
capable of altering the predetermined bit rate at which messages are transmitted, 

10 while communicating with the plurality of remote devices. In this embodiment, the 
receiver receives messages from the remote devices via the common bus at the same 
predetermined bit rate at which the network controller previously transmitted the 
messages to the remote devices. This makes the receiver capable of receiving 
messages as the transmitter alters the predetermined bit rate without relying upon any 

1 5 clock signals. In one embodiment, the network controller transmits an example 
message to the remote devices at an altered bit rate following alteration of the 
predetermined bit rate to insure the remote de^dces are in sync with the network 
controller. In a fiirther embodiment, the network controller issues a baud select 
command to the transmitter that defines the predetermined bit rate at which the 

20 messages will be transmitted. 

As previously stated, in operation, the network controller works in 
conjunction with a network protocol having alow-level instmction set to allow the 
network controller to communicate with either one or several remote devices at a time 
across the network. Therefore, in various embodiments, the network protocol is 

25 configured in either a Manchester encoding or a Universal Asynchronous Receiver 
Transmitter (UART) protocol, depending upon the command protocol the remote 
devices are capable of understanding. In one embodiment, the network controller and 
the remote devices are preconfigured to operate dther in the Manchester encoded 
form or in the UART encoded form, fii another embodiment, the network controller 

30 receives a command protocol select command such that the subsequent configuration 
of the network controller is based upon the command protocol select command. In 
another embodiment, the network controller sends the protocol select command to the 
transmitter and receiver to identify the command protocol according to which the 
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plurality of remote devices are capable of communicating, and the transmitter and 
receiver thereafter transmit and receive messages, respectively, in accordance with the 
command protocol identified by the protocol select command. As stated above, the 
sunplicity of the network protocol allows the network controller of the present 
5 invention to control remote devices that lack a processor and, instead, comprise state 
machines. 

Because the network controller controls various remote devices via a 
common bus and insures time-determinism in a precise manner, the network 
controller operates using an addressing scheme. In one embodiment, the transmitter 

10 transmits messages comprising a command and an address of atleast one remote 
device. Further, the transmitter simultaneously transmits messages to a pluraUty of 
remote devices in accordance with a command and an address representing a group of 
devices. In this embodiment, each remote device is capable of reacting and 
responding to an assigned unique address and/or one or more assigned group 

15 addresses. The group address transmission enables the transmitter to direct a message 
to a group of remote devices. In a further embodiment, the transmitter can 
additionally transmit messages to individual remote devices in accordance with a 
unique logical addresses assigned to each of the pluraUty of remote devices. In 
another embodiment, the transmitter is also adapted to transmit messages to all of the 

20 pluraUty of remote addresses in accordance with a global address. 

Once configured, the network controUer can then transmit messages between 
itself and the remote devices according to the same command protocol with which the 
pluraUty of remote devices are capable of understanding. In embodiments wherein 
the network controUer transmits messages based iipon the Manchester encoding 

25 command protocol, the network controller transmits the messages in either 

synchronous or asynchronous mode. These messages, transmitted in the Manchester 
encoding command protocol, comprise a sync portion, a message body and a parity 
flag, with the value of each transmitted bit defined by a voltage transition between 
first and second states. In one embodiment wherein the network controUer transmits 

30 messages in the synchronous mode and includes a dock transmitter, the network 
controUer is capable of transmitting messages via the transmitter while concurrendy 
transmitting a clock signal to the of remote devices via the clock transmitter. And, 
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when operating in asynchronous mode, the network cjontroller transmits messages at a 
predetennined bit rate -without transmitting a dock agaal. 

In embodiments where the network controller transmits messages according 
to the UART command protocol, the network controller transmits the messages at a 
5 predetermined bit rate and according to a non-retum-to-zero (NRZ) bit format. In 
another embodiment, also where the network controller transmits messages according 
to the UART command protocol, the network controller transmits an idle pattern to 
reset the plurality of remote devices prior to transmitting each message. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic block diagram of an electrical network system 
implementing one embodiment of the network controller of the present iavention; 

FIG. 2 is a schematic block diagram of the network controller accord ing to one 
embodiment of the present invention; 
15 FIG. 3 is a block diagram illustrating the operational steps of the network 

controller during operation of a device inventory word search according to one 
embodiment of the present invention; 

FIG. 4 is a block diagram illustrating the operational steps of the remote 
device during operation of a device inventory word search according to one 
20 embodiment of the present invention; 

FIG. 5 is a schematic diagram of an electrical network system implemented on 
an aircraft; and 

FIG. 6 is a schematic diagram of a translation device implemented with an 
electrical network system, such as that illustrated in FIG. 5. 

25 

DETAILED DESCRIPTION OF THE INVENTION 
The present invention now will be described more fully hereinafter with 
reference to the accompanying drawings, in which preferred embodiments of the 
invention are shown. This invention may, however, be embodied in many different 
30 forms and should not be construed as limited to the embodiments set forth herein; 
rather, these embodiments are provided so that this disclosure will be thorough and 
complete, and will fully convey the scope of the invention to those skilled in the art. 
Like numbers refer to like elements throughout. 
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As described above, many conventional analog network systems reqiiire 
separate sets of dedicated wires and signal conditioners to run from each component 
within the system, which can be expensive, bulky, heavy, hard to install and maintain, 
and suflfer from signal degradation due to DC resistance of the wires and noise, 
5 Additionally, many conventional digital network systems demand complicated 
communication schemes requiring processors and, thus, suffer from high overhead 
network communication. These conventional distal network systems may also 
require separate dock signals, may not support both acquisition and control, and may 
only support short network lengths. Moreover, many conventional digital network 

10 systems do not operate in a time-deterministic manner and have bulky network 
interfaces, slow network data rates and alow network device count. 

As described in greater detail below, the present invention remedies these and 
other problems by providing a digital network system that allows various remote 
devices, such as sensors, actuators and subsystems, to communicate over an 

1 5 inexpensive, simple and high-speed, yet robust, network line with a ample message 
protocol, small contiponent size and low wire count. Advantageously, the network 
controller of the present invention connects to the remote devices via a common 
network, thereby permitting the various remote devices to share the same wiring for 
communicating with the network controller. Additionally, the network controller of 

20 the present invention allows for minimally sized devices, longer network Unes, and 
insures time-determinism in a precise manner. The network controller also supports 
both acquisition and control, acquires data simultaneously from the remote devices 
and operates with synchronized data samples from the remote devices. 

Further, the network controller of the present invention operates in 

25 conjunction with a network protocol that allows the controller to communicate with 
either one or several remote devices at a time across the network. Importantly, the 
network protocol used by the network controller has a fixed, low-level instruction set. 
Due to the simplicity of the network protocol, the network controller of the present 
invention can operate with remote devices that lack a processor and, instead, comprise 

30 a state machine that use pass through logic to process the commands and data between 
the network controller and the remote devices. . 

As mentioned above, the network controller of the present invention is used to 
intercoimect various remote devices via a common network bus. FIG. 1 is an 
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illustration of one embodiment of the implementation of the network controller of the 
present invention. This illustration is provided so that a more complete understanding 
of the present invention may be appreciated. It must be understood that the present 
invention is not limited to this configuration and may be embodied in maay different 

5 network systems. 

With regard to FIG. 1, a general embodiment of a networked system 25 in 
which the present invention is used is shown. Specifically, the networked system 
iacludes a host computer 30 such as high-level processor or personal computer that 
processes data from and sends commands and data to remote devices 36, such as 

10 sensors, actuators and subsystems, located at desired points in the network. The 

networked system further includes the network controller 32 of the present invention 
connected between the host computer and a network bus 34. Importantly, the network 
controller of the present invention comprises a part of a digital network that also 
comprises a common bus intercoimecting the network controller and remote devices. 

15 In some embodiments, the remote device 36 may include a network device 

interface (NDI), not illustrated, connected to the network 25. The NDI is used in 
embodiments in which transducers, whether sensors or actuators, cannot communicate 
directly with the network controller. The NDI receives and interprets commands 
from the network controller and controls signal conditioning, such as receiving data 

20 from sensors or activating actuators, based on the commands and data from the 

network controller. The NDI &rther includes a block of stack memory for storing the 
data and/or messages from the sensors and/or actuators. In this embodiment, the 
network controller is capable of pushing data on or popping data off of the top the 
stack memory. Also, the NDI can receive, format and send data from the signal 

25 conditioning devices to the network controller. As the present invention is focused on 
the controller, the various embodiments below do not mention the communication 
between the network controller and M)I, but instead depict the remote device as 
communicating with the network controller. It must be understood that in some 
embodiments, the remote devices will include needed components to properly 

30 communicate with the network controller, while in other embodiments, a NDI will be 
needed. As such, the various communications of the remote devices discussed bdow 
may be performed by either the remote device or a NDI. A complete detailed 
disclosure of such a NDI is provided in U.S. Provisional Patent Application Number 
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60/254,136 entitled: NETWORK INTERFACE DEVICE FOR DIGITALLY 
INTERFACING REMOTE DEVICES TO A CONTROLLER VTA A NETWORK 

and filed on December 8, 2000, and U.S. Patent Application Number 09/735,146 
entitled: NETWORK DEVICE INTERFACE FOR DIGITALLY INTERFACING 
DATA CHANNELS TO A CONTROLLER VIA ANETWORK filed on December 
1 2, 2000. The contents of this patent application are incorporated in its entirety herein 
by reference. 

As described above, the network controller 32, coupled with the network 
protocol and host computer 30, allows the network 25 to communicate with various 
remote devices 36, such as sensors, actuators and subsystems. More particularly, the 
network controller controls a network bus 34 that interconnects the remote devices to 
the network controller. The network controller uses the network bus to send 
commands to the remote devices and receive responses fi^om the remote devices. 
Within the network, the network controller is typically controlled by the host 
computer. By defeult, the host computer is generally responsible for initializing the 
network bus at startup, sending the initial commands and resetting all hardware. 
Additionally, the host computer acts as the initial network controller at power-up. 
Further, in some embodiments, the host computer may also act as the operational 
network controller. 

Likewise, the network controller 32 may also contain the intelligence to be 
responsible for initializing the bus at startup, sending the initial commands and 
resetting all hardware. Additionally, the network controller may act as the master 
network controller, i.e., host computer 30, at power-up, thus having the capability to 
issue a stream of preprogrammed commands to the network and return data through 
the network controller to the host computer. The network controller may also alter the 
message arguments of the preprogrammed commands from data provided by the host 
computer. Such an embodiment can permit processor-fi:ee, time-deterministic 
operation of the network while still permitting control information to be processed 
and passed to the network. 

The network controller 32, on the other hand, performs the functions of the 
host computer 30 when it passes control to the network controller. Because the 
network controller is capable of performing, and many times performs, the functions 
of the host computer, the following description of the netwoifc, including the functions 
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of the host computer, will be described with reference only to the network controller. 
Additionally, although several of the functions of the network controller are 
performed either through hardware, such as state devices and/or Application Specific 
Integrated Circuits (ASIC), or through software, it should be noted that many 
5 hardware functions can be performed using software and vise versa without departing 
from the spirit and scope of the present invention. 

In addition to the network controller 32 operating as the master network 
controller, i.e., host computer 30 in one embodiment, in another embodiment the 
network controller can be configured to operate as a remote device 36 on the network 

10 25. In this embodiment, the network controller can act as a NDI to another, 

subsystem host computer on the network 25. In this embodiment, the network bus 34 
provides an intersystem connection between the host computer and the subsystem 
host computer. As such, the various communications between the network controller 
and the remote devices discussed below may be performed either between the 

1 5 network controller and the remote devices or NDIs, or the network controller and 
other network controllers, acting as NDIs. 

In addition to the capabilities of the NDI, operating as a remote device 36, the 
network controller 32 adds additional memory capabilities that may not be available 
in the NDI. The NDI contains a set of memory, referred to as a Transducer Electronic 

20 Data Sheet (TEDS), that stores configuration and calibration data. Each network 

device, including each network controller, will contain a TEDS. Some of the memory 
areas included within the TEDS are not changeable by the user. Other areas are 
mandatory user areas for iaformation such as logical and group addresses and an 
ASCn description area, and yet other areas are not mandatory. Advantageously, for a 

25 network controller operating as a remote device, this additional space can be used to 
access large blocks of memory, typically random access memory (RAM) and/or 
EEPROM memory, within the remote device's host computer. This allows the master 
network controller to access not only the stack memory, like on an NDI, but also the 
RAM and/or EEPROM memory locations in the remote device's (i.e., network 

30 controller acting as a NDI) host computer. 

Because the network controller 32 of the present invention connects to the 
remote devices via a common network 25, the network controller does not require 
dedicated connections to each remote device to control the network. The network 
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controller instead uses aa addressing scheme to assign and control each of the remote 
devices 36. To operate the network, each remote device is assigned one or more 
addresses, including a logical address, global address and, if configured, one or more 
group addresses. A logical address is an address recognized by a single remote device 
5 that the network controller uses to direct a command, or request, to a particular remote 
device. A global address, on the other hand, is an address recognized by all of the , 
remote devices on the network which the network controller uses to exchange 
universal data and commands. For example, the global address scheme permits the " 
network controller to universally initialize or reset all of the remote devises. A group 

10 address is an address that can be recognized by a particular group of remote devices 
on the network which the network controller uses to exchange group data and 
commands. For example, the group address scheme permits the networis controller to 
set up time deterministic triggers for groups of remote devices at various sample rates. 
Refening now to FIG. 2, which depicts the network controller 32 electrically 

1 5 connected to a host computer 30 and a network bus 34. The network controller can 
contain an optional memory device 58, typically an EEPROM, RAM or Dual Ported 
RAM, that is electrically connected to the host computer. The memory device is 
designed to house a set of microcodes comprising control type commands for the 
network controller, such as timmg schemes for collecting data from or prodding data 

20 to the remote devices 36 connected to the network bus. In addition, the memory 
device is designed to house the network protocol commands for the remote devices, 
such as measuring data and transmitting data to the network controller. Optionally, 
the host computer can additionally select microcode commands 112 from the memory 
device for the network controller to perform. The network controller also includes a 

25 bus controller 44 that receives the microcodes, either from the memory device or the 
host computer, processes the microcodes and passes data when specified by the 
microcode. 

The network controller fiirther includes a bus clock generator 56. The bus 
clock generator, runningfrom either alocal oscillator 57 or an external dock 59 in 
3 0 various embodiments, generates multiple timing signals that the network controller 
can use for various functions, such as logic operations, baud generation, synchronous 
clock generation and asynchronous message receiving. The local oscillator can be 
selected to run at a multitude of different fi-equencies. For example, in one 
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dis- 
embodiment, the local oscillator operates at a frequency of 80 MHz. Because many 
of the fonctions of the network controller that use the clock do not require such a high 
frequency, the bus clock generator divides the local oscillator frequency by a 
specified divisor, typically sixteen. This divided clock signal is available as an output 
signal 61 that can be used to synchronize the network controller 32 to another network 
controller, not shown. Similarly, the external clock input 59 can be used to 
synchronize the network controller with another network controller, not shown. 

A controller transmitter 48, electrically connected to the bus controller 44, 
receives the data from the bus controller and formats the data into bit frames based on 
the communications protocol understood by the remote devices, such as a Manchester 
encoded Bi-Phage Sensor and System (BiSenSys) protocol. The BiSenSys protocol 
encodes messages by translating a voltage transition from a high state to low state as a 
binary " 1 " and a vdtage tranation from a low state to a high state as a binary "0." 
The controller transmitter then sends the bit frames, along with a clock signal, via a 
data transmitter 50 and a clock transmitter 52, respectfiiUy, to the network bus 34 and, 
eventually, the remote devices. A data receiver 54, included within the network 
controller, receives message frames from the remote devices, through the network bus 
34, and passes the data to the network receiver 46. The network receiver, in turn, 
processes the message frames, formats them from their encoded form and passes them 
to the host computer 30. Additionally, the network receiver uses the various 
characteristics of the received message frames to determine any transmission errors 
within the message frames, such as message frame errors 120, bi-phase encoding 
errors 114, parity errors 116 and error flag errors 118. 

The elements of the network controller 32, including the bus controller 44, 
bus clock generator 56, controller transmitter 48, data transmitter 50, clock transmitter 
52, data receiver 54 and network receiver 46 may be of a variety of types. But while 
they must all be compatible with one another, they can comprise any of a variety of 
typical such elements, such as is known to those skilled in the art. Additionally, 
however, the elements that send and receive data from the network bus, are selected 
based on the type of network implemented. For example, a physical layer such as RS- 
485, or TIA/EIA-485-A, standard half-duplex multidrop network allows multiple RS- 
485 compliant transmitters and receivers to reside on a single network line, with only 
one transmitter active at any given time. Additionally, the network controller can 
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support a full duplex configuration network bus 34 where messages are 
simultaneously transmitted between the network controller and an active remote 
device 36, Also, while the elements described and illustrated are separate from one 
another, they can be implemented in a single or in multiple combined elem^ts, such 
as in a field programmable gate airay 60, without departing from the spirit and scope 
of the present invention. 

The physical layer can consist of many different transfer configurations, 
including differential twisted pair copper wire, coaxial copper wire, fiber-optic cable 
and radio frequency transmission. Physical layers, such as the RS-485 standard, 
allow the network to support high speed bit transfer rates. But in embodiments where 
low bit rates are required, such as in the kilobit range, a single-ended copper network 
bus, with a common, ground return path may be used. In such embodiments, the 
controller transmitter 48 and network receiver 46 can be used to transmit messages 
and clock signals to and receive messages from the remote devices, and elements 
outside the field programmable gate anay 60, such as a separate data transmitter 50, 
clock transmitter 52 and data receiver 54, are not required. 

As mentioned above, the network controller 32 of the present invention 
operates in conjunction with a protocol that allows remote devices to communicate 
over a simple and high-speed yet robust digital multi-drop network 25. It must be 
understood that any applicable network protocol or physical layer, such as fiber-optic 
or wireless schemes, could be used in conjunction with the network controller of the 
present invention. However, described bdowis a particular protocol that provides 
several advantages when used in the network 25 illustrated in FIG. 1 . One important 
advantage being that the simplicity of the protocol allows the network controller to 
communicate with remote devices 36 comprising state machines, as opposed to high- 
level processors. 

In operation, the network 25 runs in various formats and modes based on the 
command protocol and communication type implemented (i.e., synchronous or 
asynchronous). The command protocol format is determined by the command 
protocol compatible with the physical layer of the operational remote devices 
connected to the network, such as the Manchester encoded format or the format 
compatible with a Universal Asynchronous Receiver Transmitter (UART) physical 
layer, such as are known to those skilled in the art. Itis notmandatory to support both 
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the Manchester encoded fonnat and UART physical layer on the network Selection 
of the format is set vdthin the netwoik controller 32 and can be selected using 
software. 

Command and data messaging within the network protocol can be formatted 

5 to operate with both the Manchester encoding and UARTs. With the Manchester 
encoding, the network protocol comprises 18-bit message frames that include 
command frames and data frames. Command frames are used to pass addresses and 
commands from the network controller to one or more remote devices. Each 
command frame consists of a command sync pattern, a 7-bit command word, a 10-bit 

10 address word and a parity bit. Data frames, can be used as arguments to command 
frames or responses from one or more remote devices issued in response to 
commands from the network controller. Each data frame consists of a data sync 
pattern, a 16-bit data word, an error flag bit and a parity bit The error bit is used by 
the remote devices 36 to inform the network controller 32 of the occurrence of an 

1 5 error within the remote device. Once the network controller receives the error flag 
from the remote device, the network controller can either issue commands such as 
Read Status Register^ discussed below, to the remote device to try and determine the 
nature of the error. Ad vantageoxxsly , the use of the error flag bit allows the network 
controller to receive output data from the remote devices along with the error flag, 

20 instead of only receiving an error notification, such as an error word. With the 

Manchester encoding, the network can operate at any data rate from DC - to a high 
bit rate such as 10 MHz or higher iq synchronous mode or at several predetermined 
bit rates in asynchronous mode. 

DistLaguished from the Manchester encoding method, in UART mode, the 

25 network 25 is designed to typically operate at one bit rate and use non-return-to-zero 
(NRZ) bit coding. UART message frames contain three required 1 1 -bit frames, 
including address, command and checksum frames, and two optional 11 -bit frames, 
including number of data and data frames, utilized depending upon the command 
issued by the network controller. The first bit in every frame will be a start bit (set to 

30 "0"). The final bit of all frames is a stop bit (set to "1"). Additionally, the tenth bit is 
used by all frames is used to identify the firstframe of a message (i.e., the address 
frame). 
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The conimiMiicationfonnat implemented by the network 25 can include either 
synchronous or asynchronous communication, depending on the operational remote 
devices or control of the network controller. Using the Manchester encoding method, 
the communication format can be enabled by the network controller 32, and 
5 automatically detected by the remote devices 36 monitoring the network for 

synchronous clock lines. The network, using the Manchester encoded method, can 
typically be used synchronously at any bit rate between DC - to a high bit rate such as 
10 MHz or higher, and the network controller and remote devices can operate 
asynchronously at several predetermined bit rates, such as 10 K, 20K, 1.25M, 2.5M, 

1 0 51^ and 1 OM bits/sec. The lower bit rates permit single-ended physical layers 
reducing wiring costs and transceiver costs. High bit rates in the Mbit/sec range 
require differential copper signaling, fiber-optic, coaxial, or some other high-integrity 
signaling physical layer. Using the UART physical layer, the network typically 
operates at 1.0 or 1.25 Mbits/sec. 

i 5 With regard to the Manchester encoding method, in the synchronous mode, 

the clock generator 56 of the network controller provides a continuous synchronous 
clock signal. The synchronous clock signal is used by the remote devices of the 
present invention in the synchronous mode to clock in data from the network 
controller and to clock data out to the network controller. 

20 With the Manchester encoding method, operating asynchronously, a 

synchronous clock signal is not transmitted, and the network controller 32 operates at 
a predetermined bit rate. During operation, the network controller may alternate 
between a synchronous and asynchronous mode. If the network controller changes to 
the asynchronous mode during operation, the bit rate is initially set at the lowest bit 

25 rate. The bit rate can then be changed using a Baud Select command, as described 
below. The remote devices 36 detect whether the network controller is operating in 
the synchronous or asynchronous mode by sensing whether the clock generator 56 is 
providiQg a synchronous clock signal, and adjusting their operation accordingly. If 
the network controller does alter the bit rate once the network enters asynchronous 

30 mode, the data transmitter 50 transmits data at the new bit rate to the remote devices. 
The remote devices, in turn, alter their ou^ut bit rate and send messages and data 
back to the data receiver 54 at the new bit rate. But before the data transmitter 
transmits operationalcommands to the remote devices, it may issue a null conamand 
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to the remote devices to insure the remote devices resynchronize with the network 
controller at the new bit rate. 

As described above, each remote device 36 is provided with a logical address 
that imiquely identifies the remote device. Further, there is a global address that 
5 addresses all channels of all remote devices, and multiple group addresses that 

address a number of remote devices. The global address is used for the exchange of 
global data and commands. The group address is an address that can be recognized 
by multiple remote devices and is used for the exchange of data and commands to a 
group or subset of remote devices on the network. Associated with the group address 

10 is a group mask stored in the remote device. The group mask is a 16-bit word, 

representing 16 predetermined network addresses, where each bit set to "1" represents 
an address of the group that the remote device belongs. 

As an example, in one embodiment, the global address is assigned as OOOOhex. 
In this embodiment, if the network controller 32 transmits the address OOOOhex, all of 

15 the remote devices will follow the command. The netwoik controller typically uses 
this command for service commands, triggering, resetting the system or testing the 
network 25. Further, in one embodiment, the group addresses are selected in the 
range of OOOlhex to OOOfhex, representing the range available in the remote device's 
group mask. In this embodiment, when the network controller transmits an address in 

20 this range to a remote device 36, the remote device will compare the group address 
with the group mask it has stored. If the bit in the group mask corresponding to the 
group address is set, the remote device will interpret and follow the command 
associated with the group address. For example, if the remote device has the group 
mask 100000001 lOObin stored, the remote device belongs to group addresses 

25 OOOfhex, 0003hex, and 0002hex. 

The group address scheme is designed to permit the network controller 32 to 
set up time-deterministic triggers for groups of remote devices 36 at various sample 
rates. Table 1 illustrates a group of sensors having different sample rates and their 
group assignments, and Table 2 illustrates the sequence for polling the sensors. 

Table 1 



Logical Address 


Device 


Sample Rate 
(Samples/sec) 


Group Address 


16 


Temperature 1 


. 125 


1 
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XjUglCal xVllUrC59 




Samole Rate 
(Samples/sec) 


Group Address 


17 


Pressure 1 


250 


1,2 


18 


Strain 1 


500 


1,2,3 


19 


Strain 2 


500 


1,2,3 


20 


Strains 


500 


1,2,3 


21 


Strain 4 


500 


1,2,3 


22 


Accelerometer 1 


1000 


1,2,3,4 


23 


Accelerometer 2 


1000 


1,2,3,4 


24 


Accelerometer 3 


1000 


1,2,3,4 : 


25 


Accelerometer 4 


1000 


1,2,3,4 



Table 2 



Command Execution Time 


Action 


0 


Issue Trigger Command to Address 1 




Poll Addresses 16 through 25 


1 msec 


Issue Trigger Command to Address 4 




Poll Addresses 22 through 25 


1 msec 


Issue Trigger Command to Address 3 




Poll Addresses 18 through 25 


1 msec 


Issue Trigger Command to Address 4 




Poll Addresses 22 through 25 


1 msec 


Issue Trigger Command to Address 2 




Poll Addresses 17 through 25 


1 msec 


Issue Trigger Command to Address 4 




Poll Addresses 22 through 25 


1 msec 


Issue Trigger Command to Address 3 




Poll Addresses 18 through 25 


1 msec 


Issue Trigger Command to Address 4 




Poll Addresses 22 through 25 


1 msec 


Restart Sequence 
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With regard to the group addresses, if the network controller 32 sends out a 
group address, the remote device will decode the address portion of the command and 
compare the group address to the group mask stored in the remote device. If the 
group mask indicates that the remote device is a member of the group address, the 

5 remote device will perform the command associated with the group address. 

As stated previously, the network controller of the present invention operates 
in conjunction with a selected protocol. In one embodiment, this protocol is designed 
to insure low-level communication control interfaces, (i.e., network controllers 32 and 
remote devices 36). This protocol makes possible the development of controller and 

1 0 network interfaces that are highly miniaturized within the network 25. If the network 
controller and remote devices are implemented using an ASIC, in conjunction with 
the protocol, the network controller and remote device can respond quickly and 
efficiently allowmg for maximized bus efficiency. 

The protocol of the present invention also has a low overhead command 

15 structure. It does not use a fixed length message. The length of the message varies 
depending on the command. This, in tum, permits the elimination of unnecessary 
data being transmitted, if it is not needed to execute a function. In addition, the 
command set associated with the protocol is minimal and straightforward allowmg the 
user to easily pass data through the network bus 34 with minimal manipulation. 

20 Generally, the commands included within the command set of the protocol fall 

into three broad categories, service commands, data commands and memory 
commands. Many of the commands of the network protocol are described below in 
Table 3. It should be noted, however, that the description of the commands below axe 
intended to be illustrative, and not exhaustive, of the commands within the command 

25 set the network controller and remote devices can interpret. Some of the described 
commands may not be implemented in some embodiments, and other commands may 
be used in other embodiments, without departing from the spirit and scope of the 
present invention. A detailed disclosure of the commands directed at remote device 
processing is also provided in U.S. Provisional Patent Application Number 

30 60/254,136 entitled: NETWORK INTERFACE DEVICE FOR DIGITALLY 

INTERFACING REMOTE DEVICES TO A CONTROLLER VIA A NETWORK 
and filed on December 8, 2000, and U.S. Patent Application Number 09/735,146 
entitled: NETWORK DEVICE INTERFACE FOR DIGITALLY INTERFACING 
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DATA CHANNELS TO ACONTROLLER VIA A NETWORK filed onDecember 

12, 2000. 

Tables 



Command (hex) 


Command Description 


Service Commands 


00 


No Op 


01 


Built in Test 


02 


Reset 


03 


Read Status Register 


04 


Device Inventory Enable 


05 


Device Inventory 


06 


Control Pass 


07 


Wake 


08 J 


Sleep 


09 


E-Calibration 


OA 


Z-Calibration 


OB 


Synchronize 


OC 


Baud Select 


OD-OF 


Reserved 






Data Commands 


20 


Trigger 


21 


Trigger and Read 


22 


Read In-Data Register Word 


23 


Read In-Data Stack Word 


24 


Read In-Data Stack Block 


25 


Query In-Data/Out-Data Stack Depth 


26 


Write Out-Data Stack Word 


27 


Write Out-Data Stack Word/Echo to In-Data Register 


28 


Write Out-Data Stack Block 


29-2F 


Reserved 
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Command (hex) 


Command Description 


Memory Commands 


30 


Set Memory Pointer 


31 


Read Memory Word with Current r ointer 


32 


'PoqH A/T pmnrv T^lnrlr with Piirretit Pointer 


33 


Write Memory Word with Current Pointer 


34 


Write Memory Block with Current Pointer 


35 


Read Memory Word with Passed Pointer 


36 


Read Memory Block with Passed Pointer 


37 


Write Memory Word with Passed Pointer 


38 


Write Memory Block with Passed Pointer 


39-7F 


Reserved 



As described previously, the host computer 30, by default, issues many 
commands 110 directly to the network25, including initializing the network bus 34 at 
startup, sending the mitial conamands and resettmg all hardware. The host computer 

5 may also send commands and receive responses directly from the network. Likewise, 
as previously stated, the network controller 32 may also contain the intelligence to be 
responsible for initializing the bus at startup, sending the initial commands and 
resetting all hardware. Also, the network controller 32 may act as the master network 
controller, Le., host computer, at power-up, thus having the capabiUly to issue a 

10 stream of preprogrammed commands to the network and return data through the 
network controller to the host computer 30. Additionally the network controller 32 
may alter the message arguments of the preprogrammed conmiands from data 
provided by Ihe host computer 30. Such an embodiment can relieve the processor of 
consuming tasks and permit processor free time-detemainistic operation of the 

1 5 network while still permitting control information to be processed and passed to the 
network. 

In one embodiment, control of the network can be passed temporarily from the 
host computer 30 or network controller 32 to a remote device 36 that has the 
capability of network control (and that may also be controlled by a host computer) 
20 using a Control Pass command. This peraoits other devices on the network bus 34 to 
issue commands and receive responses without the network controller 32 scheduling 



wo 02/46938 



PCTAJSOl/47393 



-22- 

the commands. Such aa application would be useful for remote devices capable of 
network control that need to acquire or pass significant information that is unique and 
not necessary for the network controller. The network controller has the capability of 
regaining control by issuing a Reset command which would perhaps conflict with 
traffic on the network bus, but would cause the remote device with temporary control 
to become silent, and allow the remote device to receive another Reset command 
indicating loss of control. 

In order for the network controller 32 to have full control over the remote 
devices 36, the network protocol includes several service commands, including 
several testing commands, such as Built-in-Tests, ErCalibration and Z-Calibration. 
To maintain remote devices and allow them to check their internal circuitry, the 
network controller can issue a Built-in-Tests command to the remote devices. While 
the network controller controls when these tests are performed, the remote device 
manufacturer defines the nature and scope of the tests performed by each remote 
device. The network controller uses the E-Calihration and Z-Calibration commands 
to generate a calibration measurement in the remote devices. Issuing an E- 
Calibration command, the network controller initiates the remote device to replace its 
input with a known reference voltage and take a measurement using the Trigger 
command, described below. Similarly, when the network controller issues a Z- 
Calibration command, the remote device shorts out its input and takes a measurement 
using the Trigger command. These commands allow the network controller to 
compare a known measurement against the actual value measured by the remote 
devices during the test. Additionally, these commands may also permit the initiation 
of an autocaUbration procedure built in to the remote device setting the devices to a 
predetermined calibration when instructed. 

Also included within the service commands are No Op, Reset, Read Status 
Register, Wake, Sleep and Synchronize commands. The network controller issues the 
No Op command to the remote devices, typically along with another command, to 
instruct the remote devices to take no action or generate any response. When the 
network controller 32 wants to initialize the remote devices 36 to their power-up state, 
the network controller issues a Reset command 102. This command is used by the 
network controller to reset the network bus 34 and remote devices when necessary, 
and used by the host computer 30 and/or network controller to regain control of the 
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network from another host computer and/or network controller that has temporary 
control of the network. Additionally, this command can be used by a remote device 
manufacturer to perfonn other resetting functions within a remote device. 

To access the status of a remote device, or multiple remote devices, the 
5 network controller issues a Read Status Register command to the remote devices. In 
response to this command, the selected remote devices will transfer the contents of its 
status register to the network controller mdicating the status of the remote device, 
such as device not ready error, device does not support command error, message 
transmission error, invalid argument error or that a built-in-test has been performed 

10 since the last status read. 

To control the power draw of the remote devices 36 on a network 25 equipped 
with current limited power leads, the network controller will issue Wake and Sleep 
commands to the remote devices. The network controller 32 uses the Wake command 
to wake up a remote device in power down mode. After recdving this command, the 

1 5 remote device will return to normal operating mode. To put a device in power down 
mode, the network controller issues a Sleep command. This command will cause a 
remote device that will not be interrogated by the netwoik bus 34 for a significant 
amount of time to reduce power draw from the network. 

Some remote devices use oversampling techniques such as Sigma-Delta 

20 converters to acquire data. To synchronize the acquisition of oversampling devices 
using the clock generator 56 of the network controller 32, the network controller 
issues a Synchronize command. When issued, the selected remote devices 
synchronize their data acquisition on the next synchronous clock edge following the 
changing center edge of the parity bit in the trigger command message. If the device 

25 has an internal clock signal for running the Sigma-Delta converter that is synchronous 
with the clock generator signal, but is some fraction of the bus clock signal, the 
remote device will align itself with the clock generator signal. This will allow 
multiple remote devices to run substantially synchronously. If the sample and hold do 
not occur at this time, the remote device manufacturer will defme the delay in clock 

3 0 cycles of the remote device. 

As mentioned above, the network controller 32 addresses each of the remote 
devices by a logical, group and global addressing scheme. To begin implementation 
of the network 25, the network controller 32 inventories the remote devices 36 on the 
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network and assigns the logical and, if configured, group addresses to those devices. 
Although the network controller can perform the inventorying and addressing by any 
conventional method, it typically performs suchfimctions via a device inventory 
session. Using the Manchester encoded method, the network controller performs the 

5 device inventory session using a universal unique identifier (UUID) stored on each 
remote device, as illustrated in FIG. 3 . Every remote device, at the time of 
manufacture, is assigned a UUID code that is derived by each device's manufacturer 
based on a defined set of criteria. The UUID consists of an 80-bit code that is used as 
a xmique identifier that no other devices can posses. Due to the excessive length of 

10 the UUID, however, it is too long for the network to implement m the addressing 
scheme for the remote devices. UART compliant devices can contain a UUID , 
however, they cannot perform a device inventory. Therefore, in UART mode, the 
network controller individually assigns logical and group addresses to UART 
compliant remote devices as those devices are connected to the network. 

1 5 During the device inventory session using the Manchester encoded format, the 

network controller 32 determines the UUIDs of the each remote device 36 by 
perfbrmmg a UUID word search. The UUID word search, in turn, includes what is 
known as a bit competition to ensure that the network controller receives and assigns 
addresses to only one particular UUID at a time. 

20 A device inventory session, begins with the network controller issuing a 

Device Inventory Enable command with a global address or a group of addresses 
(from a previous device inventory). At this point all devices within the address group 
are in device inventory mode. Once in the device inventory mode, the address field in 
the command frame becomes a fimclion code field (hereinafter fimction codes will be 

25 represented in parenthesis after its respective command) as illustrated in FIG. 2 and 
blocks 200 and 300 of FIGS. 3 and 4, respectively. The network controller then 
issues a Devzce Inventory (New UUID Word Search) command to the remote devices 
indicating that the session is beginning a new UUID word search, as illustrated in 
block 201 of FIG. 3 and block 302 of FIG. 4, Then, the network controller begins the 

30 bit competition by issuing Device Inventory (UUID Bit Competition, No Dropouts) 
command, instituting what is known as a ''No Dropout" fimction wherein the devices 
identify and evaluate the least significant bit of their respective UUIDs, as shown in 
block 204 ofFIG. 3 and blocks 304 and 306 of FIG. 4. If the identified bit is a "0," 
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the remote device transmits a pulse on the network 106 to the network controller, as. 
shown in FIG. 2 and blocks 308 and 310 of FIG. 4. If a pulse is detected on the 
network and the current bit is not the eighlielhbit (80) (i.e., the most significant 
UUID bit), the network controller stores the signal as a "0" in a UUID memory 

5 location, as shown in blocks 206 and 208 of FIG. 3 and block 312 of FIG. 4. If the 
remote device' s current bit is a "1/' the remote device doesn't send a pulse to the 
network controller. If no remote devices send a pulse to the network controller and 
the identified bit is not the eightieth bit, the network controller stores a"l" in the 
UUID memory location, as illustrated in blocks 212 and 214. While the UUID 

10 memory location can comprise any conventional device fhatis capable of atleast 
temporarily storing values, it typically comprises a shift register. 

After the remote devices 36 evaluate the identified bit, each remote device 
shifts the identified bit into a secondary location and identifies its next least 
significant UUID bit, as illustrated in block 314 of FIG. 4. If the network controller 

15 32 has stored a " 1'* in the UUID memory location, the network controller reissues the 
Device Inventory (UUID Bit Competition, No Dropout) command to the remote 
devices, as illustrated in block 216 of FIG. 3. The remote devices then repeat the 
process identified above depending upon whether the newly identified bit is a "0" or 
" 1 If, on the other hand, the network controller has stored a "0" in the UUID 

20 memory location, the network controller issues what a Device Inventory (UUID Bit 
Competition, I 's Dropout) command, initiatiug what is known as a "1' s Dropout" 
function to the remote devices, as shown in block 210 of FIG. 3 and block 326 of FIG. 
4. If a remote device's bit stored in the secondary location is a "1," the remote device 
exits the bit competition and waits for a New UUID Word Search command to reenter 

25 the competition, as shown in block 326. If the remote device's bit stored in the 
secondary location is a "0," the remote device evaluates its newly identified bit, 
following the procedure described above. The procedure then continues with each of 
the remote devices' UUID bits, completmg 81 iterations of the procedure to allow for 
the winning remote device to determine it won the bit competition, as shown in blocks 

30 218 and 220. 

As each remote device's UUID is found by winning the bit competition, as 
shown in block 316 of FIG. 4, the remote device 36 is assigned its logical and group 
addresses which are stored along with any desired TEDS information needed in the 
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remote device, as illustrated in blocks 221 and 222 of FIG. 3 and blocks 318-324 of 
FIG. 4. This information is typically stored in a memory device, such as an 
EEPROM, on the remote device. The network controller 32 then issues the Device 
Inventory (Protect/Exit Device Inventory Mode) command which causes the winning 

5 remote device to exit the device inventory session, as shown ia block 223 of FIG. 3 . 

The network controller then starts the procedure over, as illustrated in block 
201, until all devices have beenidmtified. The network controller recognizes when 
aU of the devices have been recognized when all 80 bits in the bus controller' s UUID 
register are "I's," as shown in block 224, When the UUID of every remote device on 

10 the network 25 has been searched and determined, the network controller 32 will issue 
BL Device Inventory (AU Exit Device Inventory) command and, thus, complete the 
inventory, as illustrated in block 225. Typically, the device inventory session will 
only have to be completed once the network is assembled or changed. But a device 
inventory session can be run at any time to verify the network configuration or to 

1 5 insure the network is configured. 

As described previously, the network 25 is capable of operating at diflferent 
baud rates. When operating in asynchronous mode, the network will default to the 
lowest baud rate configured for the network. The network controller 32 can change 
the baud rate of data transmission by issuing a Baud Select command 108, as shown 

20 in FIG. 2. To insure the remote devices 36 resynchronize at the new communication 
speed with the network controller, the network controller must issue a No Op 
command following the Baud Select command. Once the network controller 32 has 
inventoried and assigned addresses to the remote devices 36, the network controller 
can issue commands to the remote devices to send data to and receive data from those 

25 devices. 

In order for the network controller 32 to have fiill control over the remote 
devices 36, the network protocol includes several data acquisition and control 
commands, such as Trigger, Trigger and Read, Read In-Data Register Word, Read 
In-Data Stack Word, Readln-Data stack Block, Query In-Data/Out-Data Stack 
30 Depth, Write Out-Data Stack Word, Write Out-Data Stack Word/Echo to In-Data 
Register and Write Out-Data Stack Block. These commands are used to address a 
sequential type of memory in remote devices that resembles a stack of memory that is 
accessed by pushing data on or popping data off of the top of a stack of memory 
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locations. To initiate an incoming data measurement in a sensor or move a value to 
an output in an actuator in all devices that belong to a logical and/or group address, 
the network controller will issue a Trigger command to those devices. Following a 
data measurement, if the network controller wants to receive the measurements taken 

5 by the remote devices, the network controller will issue a Read In-Data Stack Word 
command to each of those devices. If multiple trigger commands are issued to the 
remote devices, the Readln-Data stack Block command issued to each device will 
return the multiple measurements taken. Additionally, along with receiving data from 
remote devices, the network controller can additionally write data to the remote 

1 0 devices by issuing a Write Out-Data Stack Word, Write Out-Data Stack Word/Echo to 
In-Data Register, or Write Out-Data Stack Block command. It should also be noted 
that even though a Read command typically follows a Trigger command, the network 
controller can issue the Read command at any time as long as the rmiote device has a 
data value stored within it. Trigger commands typically follow a write command to 

15 the remote device, which then cause the output of the remote device to be updated 
with the value or group of values of the previous Write Out-Data commands. 

To initiate a measurement cycle in a remote device 36 and immediately 
transmit the results of the previous measurement cycle onto the network bus 34, the 
network controller 32 will issue a Trigger and Read command. Because the network 

20 25 generally only supports data transmission from a single remote device at any given 
time. Trigger and Read commands are generally limited to unique logical addresses 
only, and will not use group addressing. To determine how many valid data words 
are stored in a selected remote device, the network controller will issue a Query In- 
Data/Out-Data Stack Depth command to a specific logical address. The remote 

25 device, in turn, responds by transmitting to the network bus the number of valid words 
stored. 

In addition to reading or writing to a data stack on the remote device 36, the 
network controller 32 can additionally read from or write to the memory of the remote 
devices by issuing a number of random access memory commands, including Read 
30 Memory and Write Memory commands. This memory can represent many different 
memory locations, such as the mandatory TEDS information contained within the 
remote device or additional memory space within the remote devices host computer. 
The network controller can read from the memory of a remote device by issuing a 
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Read Memory command. To read a length of memory, either a word or block, the 
network controller will issue a Read Memory Word with Passed Pointer command 
and additionally specify the memory location. Additionally, the network controller 
can set the remote devices memory pointer by issuing a Set Memory Pointer 
5 command and then issue a Read Memory Word with Current Pointer command . 
Likewise, the network controller can write to either a word or block of memoiy on a 
remote device by issuing a Write Memory Block with Passed Pointer command and 
additionally specify the memory location. Additionally, the network controller can 
set the remote devices memory pointer by issuing a Set Memory Pointer command 

10 and then issue a Write Memory Blockwith Current Pointer command. 

Referring now to FIG. 5, as previously stated, the avionics industry provides a 
typical appHcation of the network controller. For example, the network controller 22 
can be used on an aircraft 10 to control and monitor iactuators and sensors. The 
aircraft can use the network to monitor various critical structural locations for strains 

1 5 12, such as wing root, wing surface, tail root, tail cord and landing gear strains, and 
accelerations 14, such as wing tip and tail tip accelerations. Additionally, the network 
can be used to monitor the pressure 16 at various critical structural locations, such as 
critical belly pressures for sonic fatigue, as well as key corrosion locations 18 for 
radar, landing gear and leading edges, and engine casing temperatures 20. 

20 The network controller of the present invention therefore allows network 

components to communicate over an inexpensive, simple and high-speed, yet robust, 
network line with a simple message protocol, small component size and low wire 
count. The network controller can also advantageously operate without the use of a 
microcontroller or processor for the network components using either a Manchester 

25 encoding or UART command protocols, thereby reduciog the overhead associated 
with an associated host processor and allowing the entire network to run via the 
controller's single clock signal. Also, the network controller supports both 
acquisition and control, acquires data simultaneously from the components and 
operates with synchronized data samples from the components. The network 

3 0 controller can be used for efficient, time-detenninistic, high-speed acquisition and 
control, and intarsystem data transfer. Further, the network controller allows for high 
component counts, longer network lines and insures time determinism in a precise 
manner. 
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As illustrated in FIG. 5, the network controller of the present invention may be 
implemented in a monitoring system for monitoring various portions of an object, 
such as an akcraft or automobile. In some embodiments, such as in an aircraft, the 
various sensors and actuators of the monitoring system may be spread throughout the 
5 aircraft at different locations of interest. For example, in some applications, the 
monitoring system may include a first set of sensors and actuators located about or 
near the tail of the aircraft, a second set at or about the wings, and a third at or about 
the coclq)it, with an elongated network bus line between the sets of sensors and 
actuators. 

10 As discussed previously, however, the use of metallic wiring, such as wiring 

made of copper, has some drawbacks due to DC resistance thatmay degrade 
commands and data transmitted on the network bus. This problem with metallic 
wiring may become troublesome in instances where there are elongated spans 
between, for example, the first set of sensors and actuators located at the tail of the 
* 1 5 aircraft and the second set of sensors and actuators localed at the wing of the aircraft. 
Specifically, an elongated metallic wiring acting as the bus link between these two 
sets of sensors and actuators may degrade command and data communication on the 
bus. 

In Hght of this, with reference to FIG. 6, in one embodiment, the present 
20 invention provides a translation device 330 that transitions from metallic wiring used 
by the network bus to connect the sensors and actuator of the first setlocated at the 
wing to metallic wiring used to interconnect the sensors and actuators of the second 
set located at the wing or cockpit using a fiber optic cable. This is advantageous 
because fiber optic cable typically does not degrade signals significantly as th^ 
25 propagate along its length, thereby allowing the first and second sets of sensors and 
actuators to be spaced relatively far apart without concerns of signal degradation 
during propagation across the distance between the first and second sets. 

For example, FIG. 6 illustrates a first metallic line 332 that is connected to a 
first set of sensors and actuators located at a position of an object and a second 
30 metallic line 334 connected to a second set of sensors and actuators located at a 

different position on the object. Connecting the first and second metallic wiring is a 
set of fiber-optic cables 336 or similar type cables that minimally degrade signals due 
to length Between the fiber-optic cables and each copper wire is a translator device 
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330 for transitioning the signals pjopagating on the metallic line into optic signals and 
vice versa. 

Importantly, in this illustrative embodiment, the metallic lines are a half- 
duplex bus, whUe the fiber-optic cable is fiiU-duplex. In hght of this, not only do the 

5 translation devices of the present invention transition the commaads and data present 
on the network bus to optical data for transmission across the fiber-optic cable, but 
they may also translate the commands and data from a half-duplex system to a full- 
duplex system and vice versa. In this embodiment, the translation devices of the 
present invention may mclude anRS-485 transducer for receiving and transmitting 

10 data. Connected to the transducer is logic that translates the commands and data 
located on the network bus between half and M-duplex for transmission across the 

fiber-optic cable and copper wires. 

'J 

Many modifications and other embodiments of Ihe invention will come to 
mind to one skilled in the art to which this invention pertains having the benefit of the 

1 5 teachings presented in the foregoing descriptions and the associated drawings. 

Therefore, it is to be understood that the invention is not to be limited to the specific 
embodiments disclosed and that modifications and other embodiments are intended to 
be included within the scope of the appended claims. Although specific terms are 
employed herein, they are used in a generic and descriptive sense only and not for 

20 purposes of Umitation. 
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WHAT IS CLAIMED IS: 

1 . A network controller for digitally directing communications with a 
plurality of remote devices via a common bus, the network controller comprising: 
5 a transmitter for digitally transmitting messages via the common bus; 

a receiver for receiving digital messages from the common bus; and 
a clock for providing clock signals to both said transmitter and said receiver, 
wherein both said transmitter and receiver are capable of selectively 
operating in either mode selected from the group consisting of a synchronous mode 
1 0 and an asynchronous mode, wherein said transmitter transmits both messages and the 
clock signals via the common bus in the synchronous mode, and wherdn said 
transmitter transmits messages at a predetermined bit rate without any accompanying 
clock signals via the common bus in the asynchronous mode. 

15 2. A network controller accordmg to Claim 1 further comprising a clock 

transmitter for digitally transmittmg the clock signals via the common bus, wherein 
said clock transmitter operates at a constant level during the asynchronous mode. 

3. A network controller according to Claim 1 wherein said clock receives 
20 a baud select command that defines the predetermined bit rate at which said 

transmitter will transmit messages in the asynchronous mode. 

4. A network controller according to Claim 1 wherein said network 
controller is capable of coramanding a remote device to at least temporarily direct the 

25 communication with the other remote devices via the common bus, 

5. A network controller according to Claim 1 wherein said receiver 
asynchronously receives messages from the common bus. 

30 6. A network controller according to Claim 1 wherein the common bus is 

selected from a group consisting of differential twisted copper wire, coaxial copper 
wire, fiber-optic cable and single-ended copper wire. 
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7. A network controller according to Claim 1 wherein the network 
controller is capable of selectively operating in either communication mode selected 
from the group consistmg of a half-duplex communication mode and a full-duplex 
communication mode. 

5 

8. A network controller according to Claim 1 wherein said network 
controller is capable of acting as a remote device while another, master network 
controller directs communications with the plurality of remote devices, including the 
network controller, via the conamon bus. 

10 

9. A network controller according to Claim 8, wherein said network 
controller is capable of interactmg with a host computer having stack memory and 
random access memory (RAM), wherein when said network controller is acting as a 
remote device, the master network controller is capable of selectively accessing either 

1 5 type of memory selected from the group consisting of the stack of sequential memory 
and the RAM. 

10. A network controller for digitally directing communications with a 
plurahty of remote devices via a common bus, the network controller comprising: 

20 a transmitter for transmittiag digital messages to the plurality of remote 

devices via the common bus at a predetermined bit rate, said transmitter being capable 
of altering the predetermiaed bit rate at whichmessages are transmitted while 
communicating with the plurality of remote devices; and 

a receiver for receiving digital messages from the plurality of remote devices 

25 via the common bus at the same predetermined bit rate at which messages were 
previously transmitted to the plurahty of remote devices such that said receiver is 
capable of receiving messages as said transmitter alters the predetermiaed bit rate 
without relying upon any dock signals. 

30 11 . A network controller according to Claim 1 0 wherein said transmitter 

transmits an example message to the at least one remote device at an altered bit rate 
following alteration of the predetermined bit rate. 
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12. A network controller according to Claim 10 wherein said transmitter 
receives a baud select command that defines the predetermined bit rate at which the 
messages will be transmitted. 

5 13 . A method for digitally communicating between a network controller 

and a plurality of remote devices via a common bus, the method comprising: 

configuring the controller based upon a command protocol according to 
which the plurality of remote devices are capable of communicating, wherein the 
plurality of remote devices are capable of communicating according to a cormnand 

1 0 protocol selected firom the group consisting of Manchester encoding and a Universal 
Asynchronous Receiver Transmitter (UART) protocol; and 

transmitting messages between the bus controller and the plurality of remote 
devices according to the same command protocol with which the plurality of remote 
devices are capable of communicating. 

15 

14. A method according to Claim 13 wherein transmitting messages 
comprises transmitting messages according to the Manchester encoding command 
protocol if the plurality of remote devices are capable of communicating according to 
the Manchester encoding command protocol, and wherdn transmitting messages 

20 according to the Manchester encoding command protocol comprises transmitting 
messages according to a mode selected from the group consisting of a synchronous 
mode and an asynchronous mode. 

15. A method according to Claim 14 wherein transmitting messages in the 
25 synchronous mode comprises transmitting messages while concurrently transmitting a 

clock signal from the network controller to the plurality of remote devices via a 
common clock transmitter, and wherein transmitting messages in the asynchronous 
mode comprises transmitting messages at a predetermined bit rate without 
transmitting a clock signal. 

30 

16. A method according to Claim 14 wherein the messages comprise at 
least one message pulse, wherein transmitting messages according to the Manchester 
encoding command protocol comprises transmitting messages in the asynchronous 
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mode, and fiirfher comprising synchronizing the messages using an edge of the 
message pulse. 

17. A method according to Claim 13 wherein transmitting messages 

5 comprises transmitting messages according to the Manchester encoding command 
protocol if the plurality of remote devices are capable of communicating according to 
the Manchester encoding command protocol, and wherein transmitting messages 
according to the Manchester encoding protocol comprises transmitting messages 
comprised of a plurality of bits, each having a value defmed by a transition between 

10 first and second states. 

1 8. A method according to Claim 13 wherein transmitting messages 
comprises transmitting messages according to the Manchester encoding command 
protocol if the plurality of remote devices are capable of communicating according to 

15 the Manchester encoding conmiand protocol, and wherein transmitting messages 
according to the Manchester encoding command protocol comprises transmittijag 
messages comprised of a sync portion, a message body and a parity flag, 

19. A method according to Claim 1 8 wherein transmitting messages 
20 according to the Manchester encoding command protocol comprises transmitting 

messages comprised of a sync portion, a message body including an error flag bit, and 
a parity flag. 

20. A method according to Claim 13 wherein transmitting messages 
25 comprises transmitting messages according to the UART command protocol if the 

plurality of remote devices are capable of communicating according to the UART 
command protocol, and wherein transmitting messages according to the UART . 
protocol comprises transmitting messages at a predetermined bit rate and accordiiig to 
a non-retum-to-zero (NRZ) bit format. 

30 

21. A method according to Claim 13 wherein transmitting messages 
comprises transmittmg messages according to the UART command protocol if the 
plurality of remote devices are capable of commxmicating according to tiie UART 
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command protocol, and wherein transmitting messages according to the UART 
command protocol comprises transmitting an idle pattem to reset tiiie pliirality of 
remote devices prior to transmitting each message. 

5 22. A method according to Claim 13 further comprising receivmg a 

command protocol select command at the controller such that the subsequent 
configuration of the controller is based upon the command protocol select command, 

23. A method accordiag to Claim 13 wherein transmitting comprises 

1 0 selectively transmitting messages in either communication mode selected from the 
group consisting of a half-duplex communication mode and a full-duplex 
communication mode. 

24. A network controller for digitally directing communications with a 
15 plurality of remote devices via a common bus, the network controller comprising: 

a transmitter for transmitting digital messages via the common bus; 
a receiver for receiving digital messages from the common bus; and 
a clock for providing clock signals to both said transmitter and said receiver, 
wherein both said transmitter and receiver are capable of selectively 
20 operating in accordance with any command protocol selected from the group 

consisting of Manchester encoding and Universal Asynchronous Receiver Transmitter 
(UART) protocol, wherein said transmitter and receiver are responsive to a command 
protocol select command that identifies the command protocol according to which the 
plurality of remote devices are capable of communicating such that said transmitter 
25 and receiver thereafter transmit and receive messages, respectively, in accordance 
with the command protocol identified by the protocol select command. 

25 . A network controller according to Claim 24 wherein said transmitter, 
while operating in accordance with the Manchester encoding command protocol, 

3 0 transmits messages according to the Manchester encoding command protocol, and 
wherein said transmitter transmits Manchester encoded messages according to amode 
selected from the group consisting of a synchronous mode and an asynchronous 
mode. 
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26. A network controller according to Claim 25 wherein said transmitter 
transmits messages in the synchronous mode while concurrently transmitting a clock 
signal to the plurality of remote devices via a common clock bus, and wherein said 

5 transmitter transmits messages in the asynchronous mode at a predetermined bit rate 
without transmitting a clock signal. 

27. A network controller according to Claim 24 wherein said transmitter 
transmits Manchester encoded messages comprised of a plurality of bits, each bit 

10 having a value defined by a transition between first and second states. 

28. A network controller according to Claim 24 wherein said transmitter 
transmits Manchester encoded messages comprised of a sync portion, a message body 
and a parity flag. 

15 

29. A network controller according to Claim 24 wherein said transmitter 
transmits messages according to the UART protocol at a predetermined bit rate and 
utilizing a non-retum-to-zero (NRZ) bit format. 

20 30. A network controller according to Claim 24 wherein said transmitter, 

while operating in accordance with the UART command protocol, transmits an idle 
pattern to reset the plurality of remote devices prior to transmitting each message. 

31. A network controller according to Claim 24 wherein said transmitter 
25 transmits messages via the common bus selected from a group consisting of 

differential twisted copper wire, coaxial copper wire and fiber-optic cable. 

32. A network controller according to Claim 24 wherein the network 
controller is capable of selectively operating in either communication mode selected 

3 0 firom the group consisting of a half-duplex communication mode and a full-duplex 
communication mode. 
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33 . A network controller for digitally directing conununications with a 
plurality of remote devices via a common bus, the bus controller comprising: 

a transmitter for transmitting digital messages via the common bus, said 
transmitter adapted to transmit messages comprising a commaad and an address of at 
5 least one remote device, said transmitter being further adapted to simultaneously 
transmit messages to a phirality of remote devices in accordance with a group address 
comprised of a plurality of bits with each bit associated with a respective group, 
thereby enabling said transmitter to direct a message to a group of remote devices by 
setting the respective bit of the group address; and 
10 a receiver for receiving digital messages from the common bus. 

34. A network controller according to Claim 33 wherein said transmitter is 
also adapted to transmit messages to individual remote devices in accordance with a 
unique logical addresses assigned to the plurality of remote devices. 

15 

35. A network controller according to Claim 34 wherein said transmitter is 
also adapted to transmit messages to all of the plurality of remote addresses in 
accordance with a global addreiss. 

20 3 6 . A network controller for digitally dire cting communications with a 

pluraUty of remote devices via a common bus, the network controller comprising: 
a transmitter for digitally transmitting messages via the common bus; and 
a receiver for receiving digital messages from the common bus, 
wherein the transmitter is capable of transmitting an indefmitely repeating 
25 sequence of predetermined messages via the common bus, the receiver is capable of 
receiving an indefinitely repeating sequence of messages from the common bus, and 
wherein the network controller is capable of altering the predetermined messages as 
the transmitter transmits messages and the receiver receives messages. 

30 37. A network controller according to Claim 36 further comprising a clock 

for providing clock signals to both said transmitter and said receiver, wherein both 
said transmitter and receiver are capable of selectively operating in either mode 
selected from the group consisting of a synchronous mode and an asynchronous 
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mode, wherein said transmitter transmits both the messages and the clock signals via 
the common bus in the synchronous mode, and wherein said transmitter transmits the 
messages at a predetermined bit rate without any accompanying clock signals via the 
common bus in the asynchronous mode. 

5 

38. A monitoring system for monitoring various locations of interest on an 
object comprisiag: 

a first set of remote devices located at a first position of interest on the object; 
a second set of remote devices located at a second position of interest on the 
1 0 ' object remote from the first position; 

a network controller for sending digital commands and data to and receiving 
data from the remote devices; and 

a common bus connecting each of the remote devices of each of said first and 
second sets of remote devices, wherein said common bus comprises: 
1 5 first electrical wiring for intercomiecting each of the remote devices of said 

first set of remote devices together, and second electrical wiring for interconnecting 
each of the remote devices of said second set of remote devices together; and 

optical fibers for interconnecting the first set of remote devices at the first 
position to the second set of remote devices at the second position, wherdn the use of 
20 said optical fibers to span from the first to the second position facilitates transmission 
of the commands and data between said network controller and the remote devices. 

39. A monitoring system according to Claim 38 fiirther comprising at least 
one translation device connected between one of said first and second electrical 

25 wiring and optical fibers, wherein said translation device translates electrical signals 
from said electrical wiring into optical signals for transmission across said optical 
fibers and translates optical signals from said optical fibers into electrical signals for 
transmission across said electiical wiring. 

30 40. Amonitoring system according to Claim 39, wherein said first and second 

electrical wiring of said common bus is half- duplexed and said optical fibers of said 
common bus are full- duplexed, and wherein said translation device translates digital 
commands and data transmitted on said common digital bus from half-duplex to frill- 
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duplex for transmission on said optical fibers and JBrom full-duplex to half-duplex for 
transmission on said first and second electrical'wiiing. 

41 . A monitoring system according to Claim 40, wherein said translation 
5 device comprises: 

a transceiver in electrical communication with said electrical wiring and said 
optical fibers of said common bus for receiving and transmitting digital coromands 
and data; and 

logic in electrical communication with said transceiver for translating 
1 0 electrical signals fi-om said electrical wking into optical signals for transmission 
across said optical fibers and translating optical signals from said optical fibers into 
electrical signals for transmission across said electrical wiring. 

42. A monitoring system according to Claim 41, wherein said logic translates 
1 5 digital commands and data from said electrical wiring into full-duplex format for 
transmission across said optical fibers and translates commands and data from said 
optical fibers into half-duplex format for transmission across said electrical wiring. 
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